Computer users commonly need to find and use information. Often they may find and use information through a graphical user interface or a command line interface. If a user wants to find a color printer near his office and configure that printer, for example, he may be able to do so through menus, drop-down lists, and the like in a graphical user interface or through entry of command lines in a command line interface.
Assume that the user selects to find and configure a color printer through a graphical user interface. If his company has 127 printers distributed though ten buildings, for instance, a drop down list of available printers may show each of these 127 printers. By reading through properties for each of these listed printers, the user determines that eighteen of these printers can print in color and that one of these eighteen is located in his building. Armed with the name of this color printer, the user may then choose to configure the printer, such as through a graphical user interface. Once complete, the user can send color print jobs to this printer.
In many situations a command line interface permits a user to find and use information with greater speed, efficiency, or power than a graphical user interface. In the above example, the user studies properties for 127 printers to find the one he wants. That may take considerable time.
Assume instead that the user finds and configures the color printer through a command line interface. A user often has two options in a situation like this. In the first, he enters a first command line (e.g., “get_printer”), reads its output, finds the printer he is looking for, and types another command line with the found information as input to the second command (e.g., “Configure-Printer printername”). This has various problems. One is that the user needs to be able to read and understand the output of the first command. This often means that the first command line outputs TEXT-encoded data (which is human readable) with a particular format and that the user has to read through it. It also means that the user has to enter a second command and enter the found information in a format and encoding usable by the second command. In many cases, this first option may also take considerable time.
In the second option, a command line interface, often through its “shell”, automates much of the user's actions with script. In this case, a user enters a command line comprising the first and second commands (and a new third command) and other information that, in total, is used to find the printer and configure it. In this case, the command line might read:
  $x=get_printer | get_printername 9 color| Configure-Printer $x
Here the user wrote a script which invokes the first command “get_printer” to get information on all the printers. It then parses the output based on which printers are in building number 9 that print in color (“get_printername 9 color”). Once the name of this printer is found, the shell invokes the command “Configure-Printer” with this printer's name, thereby configuring that printer.
While this second option may be powerful and efficient, it also has a problem. Commands are type-specific; they generally accept and output data in a particular type (e.g., encoded and formatted in XML). If the first command “get_printer” generates TEXT-encoded and formatted data but the “Configure-Printer” command does not accept TEXT-encoded and formatted data exactly, the Configure-Printer command will fail.
To address this problem, many creators of commands for command lines have standardized them to output data and accept input data only when it is TEXT-encoded. But TEXT-encoded data can be difficult to parse and/or parsing it can be prone to error since there is no standard format.